I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Can you not fuzz the already-public https://docs.rs/lightning/latest/lightning/ln/onion_payment/fn.peel_payment_onion.html ? That would also include additional HTLC validation logic that would be good to fuzz vs just the low-level decoding logic.

Can you not fuzz the already-public https://docs.rs/lightning/latest/lightning/ln/onion_payment/fn.peel_payment_onion.html ? That would also include additional HTLC validation logic that would be good to fuzz vs just the low-level decoding logic.

The current target I'm working on is designed to decode the onion only. There is a custom mutator that helps the fuzzer build valid onion packets that the Lightning implementations will unwrap.

I think it would be worthwhile to have a higher-level target for fully validating an update_add_htlc message, but it would be a different target.

If you want to see:
bitcoinfuzz/bitcoinfuzz#330

Codecov Report

❌ Patch coverage is 62.50000% with 81 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.36%. Comparing base (fd85279) to head (57c9827).
⚠️ Report is 10 commits behind head on main.

@@            Coverage Diff             @@
##             main    #4276      +/-   ##
==========================================
- Coverage   89.37%   89.36%   -0.02%     
==========================================
  Files         180      180              
  Lines      139395   139399       +4     
  Branches   139395   139399       +4     
==========================================
- Hits       124591   124576      -15     
- Misses      12216    12235      +19     
  Partials     2588     2588              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Right, but you can fuzz something higher-level and generally get the same results, just with more checks so that its more realistic in terms of how LDK handles it (if theres a crash in higher-level logic we want to know!). You might have to allow a few more cases where our higher-level logic rejects things, but that should be doable.

Right, but you can fuzz something higher-level and generally get the same results, just with more checks so that its more realistic in terms of how LDK handles it (if theres a crash in higher-level logic we want to know!). You might have to allow a few more cases where our higher-level logic rejects things, but that should be doable.

Differential fuzzing requires comparing equivalent operations across implementations with matching inputs and outputs. The current target is specifically designed to test onion decoding in isolation, using a custom mutator that builds valid onion packets for each implementation to unwrap.

If I fuzz peel_payment_onion in LDK, the additional HTLC validation logic would cause output differences unrelated to onion decoding correctness, making it harder to identify real discrepancies.

A higher-level target that validates full update_add_htlc messages would be valuable, but it would be a separate fuzz target with different goals.